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Editor’s Note 

Simple Network Management Protocol 
(SNMP) originated in the Internet commu- 
nity as a means for managing TCP/IP net- 
works and Ethernet networks. During 
1989, SNMP’s appeal broadened rapidly 
beyond the Internet, attracting waves of us- 
ers searching for a proven, available, 
multivendor-network monitoring method. 


—By L. Michael Sabo 
Communications Architect SSDS, Inc. 
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Report Highlights 

The Simple Network Management Proto- 
col (SNMP) is a viable alternative to the 
ISO CMIP over TCP/IP (CMOT) protocol. 
Originally defined to manage TCP/IP net- 
works, SNMP can also be used to manage 
OSI networks. “‘Agents’’, ““managers’’, and 
“Management Information Bases” com- 
bine to control network devices. Non- 
SNMP devices can be managed with proxy 
agents. SNMP’s designers created a suc- 
cessful vehicle for multivendor network 
management; however, the protocol itself is 
less important than what users can do with 
the data. This report explains SNMP’s ar- 
chitecture, details its history and imple- 
mentation, and discusses its advantages 
and disadvantages. 
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SNMP History 


SNMP evolved from the Simple Gateway Management 
Protocol (SGMP), formalized in November 1987 by 
Chuck Davin of MIT (formerly with Proteon); Jeffrey Case 
of the University of Tennessee/SNMP Research, Inc.; 
Mark Fedor of NYSERNet; and Martin Schoffstall of NY- 
SERNet. SGMP was an early attempt to address the issue 
of network router management under TCP/IP. While 
SNMP is similar to SGMP in architecture and design phi- 
losophy, the syntax is different and the two protocols are 
incompatible. 

In August 1988, the same four SGMP authors formal- 
ized SNMP as an Internet Draft Standard. In April 1989, 
SNMP became an Internet Recommended Standard (RFC 
1098). Table 1 lists the current SNMP RFCs. 

The Internet Activities Board (IAB) is currently exam- 
ining both SNMP and OSI’s Common Management Infor- 
mation Services and Protocol over TCP/IP (CMOT) as po- 
tential solutions for TCP/IP network management. 
Although many analysts view CMIP over the OSI stack as 
the preferred long-term solution for network management, 
TCP/IP implementations are widely available today and 
will continue in use for some time. Furthermore, SNMP is 
eclipsing CMOT as the interim TCP/IP solution. 


Using SNMP 

Using SNMP, a network administrator can address queries 
and commands to network nodes and devices. It can be 
used to monitor network performance and status; control 
operational parameters; and report, analyze, and isolate 
faults. The protocol performs these functions by carrying 
management information between managers and agents. 


SNMP Architecture 


SNMP operates on three basic concepts: manager, agent, 
and the Management Information Base (MIB) (see Figure 
1). 

A manager is a software program housed within a Net- 
work Management Station. The manager has the ability to 
query agents, receive agent responses, and set specific vari- 
ables using various SNMP commands. 

An agent is a software program housed within a man- 
aged network device (such as a host, gateway, terminal 


Figure 1. 
SNMP Architecture 


SNMP has three architectural 
components: manager, agent, 
and MIB. Agents collect man- 
agement information through 
instrumentation and store the 
information in a database 
called the MIB. The agent will 
provide management informa- 
tion to an SNMP manager 
upon request. 


SNMP Network 
Management Station 
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server, etc.). An agent stores management data and re- 
sponds to the manager’s data requests. 

The Management Information Base (MIB) is a database 
of managed objects, accessible to agents and manipulated 
via SNMP to provide network management information. 


The MIB 

The MIB conforms to the Structure of Management Infor- 
mation (SMI) for TCP/IP-based Internets, as described in 
RFC 1155. This SMI, in turn, is modeled after OSI’s SMI, 
as defined in Draft Proposal (DP) 2684. While the SMI is 
similar for both SNMP and OSI environments, the actual 
objects defined in the MIBs are different. 

SMI conformance is important, since it means that the 
MIB is capable of functioning in both current and future 
SNMP environments. In fact, the Internet SMI and the 
MIB are completely independent of any specific network 
management protocol, including SNMP. 


The Internet-Standard MIB 


Each SNMP agent contains instrumentation that, at mini- 
mum, must be capable of gathering “Internet-standard 
MIB” objects specified in RFC 1156 (May 1990). Such ob- 
jects include network addresses, interface types, counters, 
thresholds, and similar data for all network devices and 
NMSs involved. (Nonstandard MIB objects are manage- 
able under SNMP, provided they are defined using SMI 
conventions specified in RFC 1155.) 

Objects are defined using a subset of Abstract Syntax 
Notation One (ASN.1), the ISO SMI specification lan- 
guage. Also, SNMP’s designers chose the ASN.1 basic en- 
coding rules to align the protocol with the OSI environ- 
ment. 

The standard MIB’s structure is logically represented 
by a tree. The root (which is unlabeled) divides into three 
main branches: ISO, CCITT, and Joint ISO/CCITT (see 
Figure 2). Within the Internet subtree, which 1s several lev- 
els down the ISO branch, exist four subtrees: Directory, 
Management, Experimental, and Private. The Experimen- 
tal subtree is reserved for Internet research purposes. The 
Internet-standard MIB, now at revision level MIB-I, finds 
its root under the Management subtree. Under the Private 
subtree is a very important branch called Enterprises. 


The Private Enterprise 


The Enterprise subtree, with its root under Private, is re- 
served for organizations wishing to develop extensions to 
the Internet-standard MIB. Organizations may apply for a 
specific Enterprise number, which uniquely identifies the 
organization’s management tree, and is essential if the de- 
vice is to manage objects other than those defined in the 
standard MIB. 


Instrumentation 


SNMP 
Protocol <-— p= 
Engine 
MIB 


Network Node with SNMP Agent 


SNMP PDUs 
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Organizations may obtain a Private Enterprise number 
(free of charge) by sending an electronic mail message on 
the Internet to jkrey@isi.edu. While the IAB controls the 
contents of the Internet-standard MIB, Private Enterprise 
MIBs are controlled by vendors or other special-interest 
groups. As of July 1991, over 250 Private Enterprise num- 
bers had been assigned. 


Agent Responsibilities 

Each agent possesses its own MIB view, which includes the 
Internet-standard MIB and, typically, other extensions. 
The agent’s MIB need not implement every group of de- 
fined variables in the standard MIB specification RFC 
1156. For example, gateways need not support objects ap- 
plicable only to hosts. This eliminates unnecessary over- 
head, facilitating SNMP implementation in smaller LAN 
components with little excess memory capacity. If a device 
supports a specific protocol (such as UDP), however, ail 
objects from that particular group (1.e., the UDP group) 
within the MIB must be supported. 


An agent performs two basic functions: 
¢ Inspects variables in its MIB 
e Alters variables in its MIB 


Inspecting variables usually means examining the values 
of counters, thresholds, states, and other parameters. Al- 
tering variables may mean resetting these counters, thresh- 
olds, etc. 

It would be possible to actually reboot a node, for exam- 
ple, by setting a specially defined variable (assuming one 
exists) to reboot=1. Most “SetRequest” commands ac- 
complish tasks such as modifying routes or interface types, 
however. (For more information on SetRequest and other 
SNMP commands, see How SNMP Works, following.) 


Figure 2. 
The Management Information Base (MIB) 
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This figure depicts the location of the Internet-standard 
MIB within the Internet tree. 
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Obtaining RFCs on the 
Internet 


RFCs are available through 
file transfer protocol (FTP) 
from Internet host NIC.DDN- 
.MIL. Log in using the user- 
name anonymous and the 
password guest. Once 
logged in, type in get RFC:R- 
FCnnnn.txt, where nnnn is 
the RCF number. For exam- 
ple, get RFC:RFC1157 will 
retrieve A Simple Network 
Management Protocol 
(SNMP). 


RFCs can also be obtained 
through electronic mail. Send 
a message to 


SERVICE@NIC.DDN.MIL 
and place the RFC number in 
the subject field. 


FTP to NIC.DDN.MIL with the 
anonymous guest login to 
obtain a current index of all 
RFCs. Once the session is 
established, type dir 
RFC:RFC-INDEX. A docu- 
ment name, such as RFC- 
INDEX.TXT.nnnn, will be re- 
turned. The nnnn represents 
the latest RFC number. Type 
get RFC:RFC- 
INDEX.TXT.nnnn to fetch the 
index for review. Type quit to 


log out. 


Manager Responsibilities 

Managers execute network manager station (NMS) appli- 
cations and often provide a graphical user interface depict- 
ing a network agents map. The manager also typically ar- 
chives MIB data for trend analysis. 


How SNMP Works 


SNMP Protocol Data Units (PDUs) 
To carry out these duties, SNMP specifies five types of 
commands, or verbs, called Protocol Data Units: 


1. GetRequest 

2. GetNextRequest 
3. SetRequest 

4. GetResponse 

5. Trap 


GetRequest and GetNextRequest 


An agent will inspect the value of MIB variables after re- 
ceiving either a GetRequest or GetNextRequest command 
(PDU) from a manager. 


SetRequest 

The agent will alter MIB variables after receiving a Set- 
Request command. An NMS, for example, could instruct 
an agent to modify an IP route using SetRequest. It is a 
powerful command and could corrupt configuration pa- 
rameters and seriously impair network service if used 
improperly. Due to SNMP’s lack of inherent security 
measures (see SNMP’s Disadvantages), some component 
vendors have not implemented or enabled SetRequest 
within their SNMP agent implementations. Many vendors 
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Table 1. RFCs Applicable to SNMP 


RFC 

Reference Title Date 

RFC 1155 Structure and Identification of Management May 1990 
Information for TCP/IP-based Internets 

RFC 1156 Management Information Base for Network May 1990 
Management of TCP/IP-based Internets 

RFC 1157 A Simple Network Management Protocol May 1990 
(SNMP) 

RFC 1158 Management Information Base for Network May 1990 

| Management of TCP/IP-based internet: MIB-II 

RFC 1161 SNMP over OSI June 1990 

RFC 1187 Bulk Table Retrieval with the SNMP October 1990 

RFC 1215 A Convention for Defining Traps for use with March 1991 
the SNMP 

RFC 1227 SNMP MUX Protocol and MIB May 1991 

RFC 1228 SNMP-DPiI—Simple Network Management May 1991 
Protocol Distributed Program Interface 

RFC 1229 Extensions to the Generic-Interface MIB May 1991 

RFC 1230 IEEE 802.4 Token Bus MIB May 1991 

RFC 1231 IEEE 802.5 Token Ring MIB May 1991 

RFC 1232 Definitions of Managed Objects for the DS1 May 1991 
Interface Type 

RFC 1233 Definitions of Managed Objects for the DS3 May 1991 
Interface Type 

RFC 1238 CLNS MIB—for use with connectionless June 1991 
Network Protocol (ISO 8473) and End System 
to Intermediate System (ISO 9542) 

RFC 1239 Reassignment of Experimental MIBs to June 1991 
Standard MIBs 

RFC 1243 AppleTalk Management Information Base July 1991 
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are working to enhance security features within their prod- 
ucts in order to offer a more secure SetRequest 
implementation. 


GetResponse 

An SNMP agent responds to an SNMP manager’s Get- 
Request, GetNextRequest, and SetRequest PDUs with a 
GetResponse PDU. The GetResponse includes the origi- 
nal request followed by the requested information. Re- 
turning the original request with the response implements 
a stateless protocol where the manager need neither track 
outstanding requests nor correlate replies. 


Traps 

Trap is a special, unsolicited command type that agents 
send to a manager after sensing a prespecified condition, 
such as ColdStart, WarmStart, LinkDown, LinkUp, Auth- 
enticationFailure, EGPneighborLoss, or other enterprise- 
specific events. Traps are used to guide the polling timing 
and focus, which SNMP employs to monitor the network’s 
state. 


Transport Mechanisms 

As mentioned previously, managers and agents exchange 
commands via messages. SNMP’s monitoring and control 
transactions are not actually TCP/IP dependent—SNMP 


FEBRUARY 1992 


only requires the datagram transport mechanism to oper- 
ate. It can therefore be implemented over any network me- 
dia or protocol suite, including OSI. There are currently 
two standard SNMP transport mechanisms: User Data- 
gram Protocol (UDP) and within Ethernet frames (as de- 
fined in RFC 1083). Currently, there are no commercial 
implementations of SNMP directly over Ethernet. All 
commercially available SNMP NMSs use UDP to ex- 
change SNMP PDUs. Figure 3 diagrams SNMP’s relation- 
ship with its transport mechanisms in terms of the OSI 
model. 


UDP 


Each SNMP message is represented entirely within a single 
UDP datagram. This lessens the message processing bur- 
den and helps to minimize the agent’s complexity. The 
SNMP message consists of: 


—version identifier—-SNMP community name—PDU 


The version identifier refers to the RFC version (currently 
at 1). An SNMP community consists of an agent and its 
associated applications. As mentioned before, a PDU is 
one of five command types. The SNMP protocol entity 
receives most messages at UDP port 161 on its associated 
host. Traps are received on UDP port 162. 
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GNMP: 


New Kid on the Block 


On May 31, 1991, the Na- 
tional Institute of Standards 
and Technology (NIST) is- 
sued its first version of the 
Proposed Government Net- 
work Management Profile 
(GNMP), a document to pro- 
vide ‘‘the standard reference 
for all Federal Government 
agencies to use when acauir- 
ing Network Management 
(NM) functions and services 
for computer and communi- 
cations systems and 
networks.” The proposal dis- 
cusses: 


¢ the scope of the GNMP 

e its applicability 

¢ its development 

¢ its specification sources 

¢ its relationship to the 
Government Open Sys- 
tems Interconnection Pro- 
file (GOSIP) 


Scope 

The GNMP mandates CMIS 
and CMIP as the manage- 
ment information exchange 
protocol. Managed Objects 


Ethernet Frames 


(MOs) are included from DMI, 
NMSIG 90/197, IEEE 802.3 
HUB Management, and other 
international standard publi- 
cations. The proposal also 
details five systems manage- 
ment functions: 


1. Object Management Func- 
tion 


2. State Management Func- 
tion 


3. Attributes for Represent- 
ing Relationships 


4. Alarm Reporting Manage- 
ment Function 


5. Event Reporting Function 


Applicability 

GNMP is mandatory for fed- 
eral agencies. This presents 
problems since some of the 
standards it adopts (CMIP, 
for example), and the GNMP 
itself, are still under develop- 
ment. The intent, however, is 
to provide guidance in select- 
ing from current NM tools 
while evolving tighter specifi- 
cations. 


SNMP over Ethernet frames, while implementable, is not 
recommended by the SNMP specification authors. While 
the SNMP message looks the same, an SNMP NMS must 
be configured to accept SNMP PDUs directly from the 
Ethernet driver. 


SNMP Proxy Agents 
Proxy agent software permits an SNMP manager to mon- 
itor and control network elements that are otherwise not 
SNMP addressable. For example, a vendor wishes to mi- 
grate its network management scheme to SNMP but has 
devices on the network that use a proprietary network 
management scheme. An SNMP proxy can manage those 
devices in their native mode. The SNMP proxy acts as a 
protocol converter, translating the SNMP manager’s com- 
mands into the proprietary scheme. This strategy facili- 
tates migration from the current proprietary environment 
to the open SNMP environment (see Figure 4). 

Proxy agents are well suited for vendors with an exist- 
ing base of non-SNMP devices communicating efficiently 
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Conclusion 

The GNMP will have a signifi- 
cant impact on the network 
management marketplace in 
the United States for two pri- 
mary reasons. First, itis a 
guideline for implementing 
accepted international stan- 
dards for network manage- 
ment. Second, the use of 
GNMP is mandated for fed- 
eral agencies and encour- 
aged for companies that do 
business with federal agen- 
cies. 


Development 

NIST conducted a survey of 
federal agencies in the sum- 
mer of 1990. The results indi- 
cated that the management 
of local area networks and 
their interconnecting bridges 
was a prime concern. GNMP 
was proposed specifically to 
address that concern. The 
Phase | implementation, pro- 
posed as GNMP Version 1.0, 
focuses on management of 
OSI model layers 1 and 2. 


Specification Sources 
NIST cites part eighteen of 
the O/W Stable Implementa- 
tion Agreements, December 
1990 as the primary specifi- 
cation source for GNMP Ver- 
sion 1.0. Other sources, how- 
ever, provided the additional 
specifications needed to pro- 
vide the minimum-required 
management capabilities. 


Relationship to GOSIP 
GNMP is the management 
information specification of 
the networks defined by 
GOSIP. GOSIP specifies the 
protocol stacks and system 
services that convey the 
management information be- 
tween managed objects and 
their managing systems. 
GNMP cites GOSIP heavily, 
and later versions of each 
document will continue to 
cross-reference each other. 


The second reason is caus- 
ing some trouble in Corpo- 
rate America. GNMP specifi- 
cally omits Simple Network 
Management Protocol 
(SNMP), widely used for net- 
work management. It is con- 
ceivable, though unlikely, that 
use of GOSIP and GNMP 
could become mandatory for 
firms wishing to conduct 
business with the federal 
government and for colleges 
and universities that receive 
federal aid, causing a costly 
retooling of entrenched net- 
work systems. 


under a proprietary scheme. By using a proxy agent, the 
vendor can reduce the investment risk of putting SNMP 
equipment into the field. 


SNMP’s Advantages 
SNMP’s major advantages are the following: 
e Its simplicity eases vendor implementation effort 


e Its memory and CPU cycle requirements are lower than 
CMIP’s 


e Its protocol has been used and tested on the Internet 

e Its products are available 

Simplicity 

SNMP’s designers successfully kept the protocol simple, 


easing vendor implementation and thereby encouraging 
widespread implementation. | | 
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Figure 3. 
SNMP Protocol Suite 


Ethernet aa " FDDI mae Layer 1&2 


This figures details the relationship between SNMP RFCs 
and the OSI Seven Layer Model. 


Memory and CPU Use 

By using only a subset of ASN.1 to define the MIB and 
implementing only five command types, agent implemen- 
tations require far less memory and fewer CPU cycles than 
most network management protocols, including CMIP. 


Tested and Used 

SNMP has a distinct advantage over CMIP in that it was 
tested and actually used by the Internet community before 
it became a standard. The RFC process of standardization, 
in fact, requires that a critical mass of users employ and 
then comment on a particular protocol or other specifica- 
tion before the authors submit it for approval. In contrast, 
ISO’s method is to develop a preliminary standard after 
much commenting, with implementation and testing as a 
poststandard process. 


Availability 

Finally, SNMP products are available now. While SNMP 
is not sophisticated, its availability will give many network 
managers the opportunity to try out multivendor network 
management and possibly discover what they need to 
manage their networks. SNMP developers and proponents 
know that the SNMP tools available now fall far short of 
satisfying user needs. Yet, the best way to clarify those 
needs 1s to get experience and redefine requirements on an 
ongoing basis. 
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SNMP proxies help a vendor migrate a proprietary network 
management scheme into the SNMP environment. 


SNMP. | Proprietary 
SNMP | Agent | Manager 


SNMP Proxy 
Implementation 


SNMP’s Disadvantages 

SNMP has several disadvantages, including the following: 
e Lack of global vision 

e Weak security features 

e Problems with the Trap command 


Lack of Global Vision 

While SNMP’s widespread deployment before standard- 
ization is an advantage in one respect (see SNMP’s Advan- 
tages), the protocol’s definition is more or less cast in 
stone—essentially without giving vendors and users out- 
side the U.S. the opportunity to voice their needs, con- 
cerns, and suggestions. The Internet Activities Board 
(IAB) is, of course, under no obligation to do so. Yet Euro- 
pean vendors, commercial users, and academicians are 
now embracing SNMP, since they share our same need for 
an open, multivendor network management protocol. 
SNMP may spread throughout the world and leave some 
non-U.S. users at a disadvantage. 

In contrast, ISO/OSI standards developers have a truly 
global vision and put a high priority on accommodating 
the viewpoints expressed by all nation representatives. In 
the OSI community, developing nations are heard on an 
equal par. The price of emphasizing universal applicability 
within OSI standards is a much slower pace of standards 
development, as compared to rapidly developed standards 
such as SNMP. 


Security issues 

There are very few security mechanisms defined as part of 
the SNMP protocol specification. For example, there is no 
capability defined to ensure that SNMP PDUs received by 
an agent actually originated from an actual manager—and 
not from an unauthorized interloper. 

Thus, vendors are reluctant to support the SetRequest 
verb on their agent implementations. SNMP does, how- 
ever, support access modes of read-only/read-write classi- 
fications for MIB variables. To employ this capability, the 
user may configure a variable such as RouteTable as read 
only. This prevents the agent from setting RouteTable to a 
potentially harmful value, if an unauthorized perpetrator 
tries to fool the agent with a SetRequest command. How- 
ever, using read-only when the variable should be defined 
read-write effectively disables the SetRequest verb on 
those variables and reduces SNMP’s functionality. 


Trap Problems 

SNMP does not define the mechanism for where a Trap 
should be sent, nor what the agent should provide as part 
of a Trap (even for standard Traps). The specification 
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merely notes that a Trap should include “interesting 
information.” Thus, Trap is implementation specific. 


Conclusion: Meeting the Goais 


SNMP’s authors adhered to several design goals during the 
protocol’s comparatively brief development time: 


1. Keep the agent simple—Minimize the number and 
complexity of the agent’s management functions. 


2. Make SNMP monitoring and control extensible— 
Accommodate unanticipated aspects of network oper- 
ation and management. 


3. Make SNMP architecture independent—Do not code 
to any particular host/gateway architectures. 


SNMP’s designers achieved the first goal by limiting func- 
tions to five and by requiring only an unreliable datagram 
service such as UDP. Simplifying the agent reduces vendor 
development costs—making it more attractive for compo- 
nent vendors to support SNMP. Widespread availability 
of SNMP agents is a prerequisite both for user acceptance 
of SNMP and for stimulating NMS vendors to integrate 
SNMP manager implementations. 


This report was prepared and updated exclu- 
sively for Datapro by L. Michael Sabo, a com- 
munications architect with SSDS, Inc., Little- 
ton, CO. Mr. Sabo is currently consulting on 
various networking and internetworking 
projects. Previously, he participated in porting 
TCP/IP to the emerging ANS! High- 
Performance Parallel Interface (HIPPI) 
Gigabit/sec LAN standard. Mr. Sabo has 
been active in integrated network manage- 
ment. He participated in developing an object- 
oriented and SNMP-based network manage- 
ment architecture for Lockheed Integration 
Services. This effort included defining numer- 
ous private enterprise management informa- 
tion base (MIB) objects to support system 
management functions. 


Mr. Sabo is a member of the SNMP working 
group and has been active in the Internet for 
six years. He is a member of the board of ad- 
visors for Datapro Network Management. He 
holds a master’s degree in data processing 
management from the University of Denver 
and a bachelor’s degree in Computer Science 
from Wright State University. 
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The second goal is realized by employing the MIB. The 
current Internet-standard MIB will evolve and expand to 
include more items—thus giving network managers more 
control over their networks. New objects are added by in- 
tegrating new subtrees into the MIB. SNMP can easily 
traverse the new structure by using the GetRequest or Get- 
NextRequest command. 

The third goal is realized via the open communications 
architecture above which SNMP operates and by SNMP’s 
capability to operate over many different transport mech- 
anisms. In addition, through the use of ASN.1 basic encod- 
ing rules, SNMP is not tied to any specific machine archi- 
tecture. 

SNMP’s designers successfully created a new vehicle for 
multivendor network management, a first step toward 
solving an increasingly critical problem. SNMP is merely a 
vehicle. The protocol itself is less important than the tools 
and applications that must be developed; how the data is 
gathered is less important than what users can do with the 
data. Most of the work lies ahead, as users gain experience 
with managing multivendor nets and determine what 
works and what does not. Hl 
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